\chapter{Secure Socket Layer}
\label{cha:Secure Socket Layer}

\section{Description}


SSL (Secure Socket Layer) was oroginally developed by NetScape as means of
securing communications across the Internet. In total there have been three
different versions, the last one was released in 1996. Since then, the idea
was continued by TLS (Transport Layer Security), whose first version was
published in 1999.

SSL is a sophisticated encryption scheme where it is not necessary for the
client and server agree on a secret key prior to data exchange. SSL uses
 pairs of public / private key encryption so that the encryption scheme can be
 setup at the time of the secure transaction. 
 
In symmetric encryption schemes the client and server must use a password that
 has been preconfigured in the client and the server. In this scheme, the client uses
  its secret key to encrypt the information. The server would use the same secret key
   to decrypt the information, being analogous operation in the reverse direction of
    communication. It is well Known that the secret keys are not suitable for
     preconfigured Web services, which would require knowledge of millions of
     keys.

     SSL solves this problem by using asymmetric keys. These keys are defined on
     pairs of public and private keys. As the name suggests, the public key is 
     available to everyone. While the private entity will be retained in the holder.
     
     By using the public key, the client can encrypt a secret key and sent it to
     the server so that, once the data have been decrypted, the client
     and the server can communicate using this key.

     The public/private key based encryption is used only for handshaking and
     secret key exchange. Once the keys have been exchanged, it will be used
     symmetric encryption. This is done for two reasons:

     \begin{itemize} 
       \item Public/private key based encryption techniques are computationally
       very expensive
       \item The secret key mechanism is needed for server to client
       communication.
\end{itemize}

TODO// say smth aboout position in OSI model

\begin{figure}[htbp]
\begin{centering}
\includegraphics[width=0.6\textwidth]{ssl_layer.png}
\caption{SSL protocol in OSI model}
\label{fig:ssl_layer}
\end{centering}
\end{figure}

\section{Operation}

If the client requests connection to a URL whose beginning is "https", then
entonces a secure connection is needed for this session. Normally a TCP
connection on the HTTPS TCP Port 443 is established.


\begin{figure}[htbp]
\begin{centering}
\includegraphics[width=0.7\textwidth]{ssl_handshake.png}
\caption{SSL handshake}
\label{fig:ssl_handhakle}
\end{centering}
\end{figure}

\begin{itemize} 
  \item The client sends a \textbf{ClientHello} command to the
  server, which includes:The highest SSL and TLS version supported by the client. Ciphers
  supported by the client. The ciphers are listed in order of preference. Data compression methods that are supported by the client. The session ID. If the client is starting a new SSL session, the session ID is 0. Random data that is generated by the client for use in the key generation process.
  \item The server sends a \textbf{ServerHello} command to the
  client, which includes: The SSL or TLS version that will be used for the SSL session. The cipher that
  will be used for the SSL session. Data compression method that will be used
  for the SSL session. SSL Version 3 and TLS have no compression algorithms defined at this time. The session ID for the SSL session. Random data that is generated by the server for use in the key generation process.
  \item The server sends the \textbf{ServerKeyExchange} command. This
  command includes the server's certificate and, optionally, a chain of certificates beginning with the
certificate of the certificate authority (CA) that assigned the server's certificate.
\item The server sends the \textbf{ServerHelloDone} command. This
command indicates that the server has completed this phase of the SSL handshake. If client
authentication will be performed, additional commands flow between the client
and the server following the ServerHelloDone command.
\item Client informs the server that it has verified the server's certificate
\item The client sends the \textbf{ChangeCipherSpec} command.
This command indicates that the contents of subsequent SSL record data sent by the client
during the SSL session will be encrypted. The 5-byte SSL record headers are
never encrypted.
\item The client sends the \textbf{Finished}command that have flowed between the
client and the server up to this point. This command is sent to validate that none of the
commands sent previously, which flow between the client and the server
unencrypted, were altered in flight.
\item The server sends the \textbf{ChangeCipherSpec} command.
This command indicates that all subsequent data sent by the server during the SSL session will
be encrypted.
\item The server sends the \textbf{Finished} command. This command
includes a digest of all the SSL handshake commands that have flowed between the server and the
client up to this point.
\end{itemize}

At this point, the client can send the symmetric secret key to the server after encrypting it with the public key received in the server's SSL
certificate. This encrypted secret key can only be decrypted using the private
key. Thus only the server is able to decrypt the message.

\section{Digital certificates}

A public key certificate is a junction point between the public key of an entity
and one or more attributes relating to their identity. The certificate guarantees
 that the public key belongs to the entity identified and that the entity has
 the corresponding private key.Public key certificates are commonly called
 Digital Certificate, Digital ID, or simply certificate. The identified entity
 is called  subject. Digital certificates are useful only if there is a
 Certificate Authority (CA) that validates them. 
 
 It is important to verify that a certificate authority has issued a certificate
 and detect whether a certificate is invalid. To prevent forgery of certificates,
  the certification authority digitally signs the certificate after authenticating the identity of a subject.
  
  Digital certificates not only provide a mechanism for implementing
  cryptographic authentication,but  also provide a secure and scalable way to
  distribute public keys in large communities.
  
  X.509 certificate format is currently the most widespread.

\subsection{X.509 certificates}

The X.509 certificate format is a standard of ITU-T (International
Telecommunication Union-Telecommunication Standardization Sector)(REFERENCE) and
ISO / IEC (International Standards Organization / International Electrotechnical
Commission)(REFERENCE) that was published for the first time in 1988. The
version one's format was extended in 1993 to include two new fields that allow support access control to directories. After using the X.509 v2 to try to develop a standard for secure email, the format was revised
  to allow the extension with additional fields, giving rise to the X.509 v3, released in 1996.
  
  \subsection{Elements of a X.509 v3 certificate}
  
  The elements of the format of  X.509  certificates are show in the Figure 
  ~\ref{fig:certificate-x509-structure}:
  
  \begin{figure}[htbp]
\begin{centering}
\includegraphics[width=0.9\textwidth]{certificate-x509-structure.png}
\caption{Structure of a x.509 certificate. Figure taken from the site:
Helpforsure: Microsoft Windows Experts \cite{Helpforsure}}
\label{fig:certificate-x509-structure}
\end{centering}
\end{figure}

  \begin{itemize} 
    \item {\bf Version:} The version field contains the version number of the
    encoded certificate. Acceptable values are 1, 2 and 3.
    \item {\bf Certificate Serial Number:} This field is an integer assigned by
    the certifying authority. Each certificate issued by a CA must have a unique serial number.
    \item {\bf Certificate Algorithm Identifier for Certificate Issuuer's
    Signature:} This field identifies the algorithm used to sign the certificate (such as RSA or DSA).
    \item {\bf Issuer:} This field identifies the CA that signed and issued the
    certificate.
    \item {\bf Validity Period:} This field indicates the time period in which
    the certificate is valid. During this period  the CA is required to
    maintain information on the status of the certificate. The field consists of
    a start date, the date when the certificate begins to be valid and the
    expiration date.
    \item {\bf Subject:} This field identifies the identity whose public key is
    certified in the field below. The name must be unique for each entity certified by a given CA.
    \item {\bf Subject Public Key Information:} This field contains the public
    key parameters and the algorithm identifier that is used with the key.
    \item {\bf Issuer Unique Identifier (Optional):} This is an optional field
    that allows the reuse of issuer names.
    \item {\bf Subject Unique Identifier (Optional):} This is an optional field
    that allows the reuse of subject names.
     \item {\bf Extensions (Optional):} X.509 v3 extensions provide a way to
     attach additional information to subjects, public keys, and so on. A
     field extension has three parts:
     \begin{itemize}
       \item  {\bf Extension Type:} It is an object identifier that provides the
       semantics and information type (string, date or other data structure) to a value of extension.
       \item  {\bf Value of the extension:} This subfield contains the current
       value of the field.
       \item  {\bf Indicator of the importance:} It is a flag that tells an
       application if it is safe to ignore the extension field if the type is
       not recognized.
       \end{itemize}
     \item  {\bf certification Authority's Digital Signature: } As mentioned
     above, certification authority digitally signs the certificate after
     authenticating the identity of a subject.
\end{itemize}
    
    The X.509 certificate format is specified in a notation system called
    Abstract Syntax One (ASN-1). For data transmission,it is used
    DER (Distinguished Encoding Rules), which transforms the certificate ASN-1
    format into a sequence of bytes suitable for transmission in real networks.

    In the Figure ~\ref{fig:certificate-example} an exmple of a X.509
    certificate is shown:
    
      \begin{figure}[htbp]
\begin{centering}
\includegraphics[width=1.1\textwidth]{certificate_example.png}
\caption{Example of a x.509 certificate. Figure taken from IBM: Software
Information Centre
\cite{IBM_software:information_centre}}
\label{fig:certificate-example}
\end{centering}
\end{figure}